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A system and method for differentiating customers according to their worth to the casino. 
Customer information is accumulated at each affiliated casino through one or more LAN- 
based management systems, updated to a central patron database (CPDB) that is coupled 
to each casino LAN through a WAN, and made available to each affiliated casino property as 
needed. Customer accounts are automatically activated and provided with data from the 
CPDB when a customer from one casino property first visits an affiliated casino property. 
Customer accounts are updated with status information based on the customer's worth to 
the casino. Customer accounts are updated with new activity data whenever a management 
system associated with the casino receives customer data from input devices, such as card 
readers, workstations, and dumb terminals, located at various venues throughout the casino. 
Customers are awarded points, based on their tracked activity at all affiliated casino 
properties. Customers also have theoretical win profiles. Customer status may be based on 
accumulated points or the theoretical win profile. When the customer is recognized at a 
gaming machine, or any location having a suitable card reader, the customer's status is 
determined in the customer account. For a special status customer, a physical 
instrumentality is activated for the benefit of the customer, such as a telephone, light, 
iockable cabinet, or the (ike. Distinguished services may also be provided once the special 
status customer is recognized. 
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activity at casinos, and in particular, to systems for tracking customers 1 gaming and non-gaming 
activity across aifiliated casino properties, for use in customer recognition and marketing 
programs. 

Background Art Substantially all casinos have implemented some form of customer 
is tracking to identify and reward their valuable customers. These tracking programs often use the 
betting activity of a customer as the basis for awarding the customer complementary rooms, 
meals, event tickets, and the like C'comps"). Typically, these tracking programs are implemented 
by providing each customer with a casino membership card which includes a machine readable 
identification number specific to the customer. Each identification number has an associated 
20 customer account that is stored in the casino's computer system and updated to reflect customer 
activity. Customers need only insert their cards in slot machines or card readers associated with 
gaming tables or give their cards to a casino employee to have their betting activity monitored 
and reflected in their accounts. Customer cards may also be used to track customer activity at 
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Technical Field This invention relates to the field of systems for tracking customer 
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casino venues, such as special events, showrooms, and hotels, through card readers and computer 
terminals manned by casino employees. 

The growth of the gaming industry has created new challenges to the way in which 
customer tracking programs are implemented. Many states and territories have recently legalized 
casino gambling, and companies have built casino properties at these new gaming locations to 
meet the demand for gaming facilities. Despite the increased number of casino properties 
affiliated with a company, conventional casino management practices continue to treat these 
casino properties as autonomous, decentralized entities that compete with each other for valuable 
customers. In particular, customer tracking at each casino property is typically controlled by 
local management and few if any attempts have been made to coordinate customer information 
across affiliated casino properties. For example, each casino has its own system that tracks 
betting data on the casino's customers. The property treats this betting data as confidential, in 
order to prevent competing casinos, including those affiliated with the property, from luring 
away valuable customers. Thus, customer tracking programs at affiliated properties remain 
fragmented, and conventional management practices provide little incentive to coordinate data 
accumulated by these tracking programs. 

Even if a casino company was to attempt some coordination of customer tracking 
programs at its affiliated casinos, the systems currently in place at various casino properties are 
too localized to integrate easily. Casino management systems are typically custom designed for 
each casino property, the customer data is limited to selected customer activity at the specific 
casino property, and the customer data accumulated by different computer systems within the 
same casino is often in different, incompatible formats. Thus, while each casino has useful data 
for its regular customers, there is no ready means for consolidating this data or making it 
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available conveniently for use at other casinos. In short, there are both operational and 
technical barriers to coordinating customer tracking programs at individual casino 
properties into national company-wide tracking and marketing programs. 

Another limitation of conventional casino management systems is that they do not 
take adequate steps to differentiate the worth of a customer to the casino on the basis of the 
customer's gaming activities. In particular, conventional systems do not adequately provide 
the customer with the use of various physical instrumentalities that enhance the customer's 
experience, based on the customer's worth to the casino. 

Summary of the Invention 

The present invention relates to a system and method for implementing a customer 
tracking and recognition program that provides various enhanced physical instrumentalities 
and distinguished services to a customer based on the customer's worth to the casino. The 
customer's worth is based on the customer's gaming and non-gaming activity alike, 
preferably at all casino properties affiliated with a casino company, but also at individual 
casinos. Preferably, each customer is issued an identity card which is associated with his or 
her own customer data in a customer database. The card enables the customer to be- 
immediately recognized any time the card is input into a suitable card reading device 
coupled to the system. This allows customer data to be accumulated across all casino 
properties and made available at any casino property without overburdening the individual 
casino properties' computer systems with unnecessary data. In addition, the customer can 
be provided with distinguished services or physical instrumentalities based on the 
customer's worth to the casino. 

A typical system comprise a local area network (LAN) at each affiliated casino 
property and a wide area network (WAN) for coupling data among the 

In one aspect the present invention may be said to consist in a computer implemented 
method for differentiating a customer at a casino property from other customers, the method 



comprising: establishing a status of the customer from at least one of an accumulated points 
of the customer or a theoretical win profile of the customer; providing at the casino property 
a gaming machine having a physical instrumentality adjacent thereto, the instrumentality 
being selectively activateable; detecting an identity carrier of the customer at the gaming 
machine having the physical instrumentality; determining the status of the customer; and 
responsive to the status of the customer being a special status, activating the physical 
instrumentality for the benefit of the customer. 

In another aspect the present invention may be said to consist in a gaming system for 
a casino property, the gaming system comprising: a gaming machine; a physical 
instrumentality adjacent to the gaming machine; identification means, coupled to the 
gaming machine, for obtaining from an indentity carrier an identification signal identifying 
a customer at the gaming machine; determination means, coupled to the identification 
means to receive the identification signal, and for determining a status of the customer by 
providing the identification signal to a computer system storing for each customer a status 
of the customer based on at least one of an accumulated points of the customer or a 
theoretical win profile of the customer, and receiving a signal of the status of the customer 
from the computer system; and activation means, coupled to the determination means and 
the physical instrumentality, and responsive to the status signal indicating a special status of 
the identified customer, for activating the physical instrumentality for the customer's 
benefit or use. 

In another aspect the present invention may be said to consist in a computer- 
implemented method for differentiating a customer from other customers at a casino 
property, comprising: operating a computer system including a database of customer 
accounts for a plurality of customers, each customer account of a customer having: 
customer identity data of the customer; a theoretical win profile for the customer as a 
function of estimated winnings from the betting activity of the customer at the casino 
property over a time period, the theoretical win profile for subsequently determining 
complementaries or services to be provided to the customer; and a status field indicating the 
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status of the customer, the status selected from a group including at least a special status 
and a non-special status, periodically updating the status in the customer account of a 
customer as a function of a current theoretical win profile of the customer; providing a 
gaming machine comprising a card reader and a light; reading at the card reader of the 
gaming machine a customer identity card of a customer to obtain customer identity data 
encoded thereon; determining a status of the customer account corresponding to the read 
customer identity data; responsive to the status of the customer being a special status, 
activating the light at the gaming machine; and providing a distinguished service to the 
customer at the gaming machine, the distinguished service limited to customers having the 
special status. 
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casino LANs. A management system associated with each casino LAN receives customer data 
from card readers, workstations, and dumb terminals, located at various venues throughout the 
casino and couples the received data to a database that is accessible to all affiliated casino 
properties. In a preferred embodiment of the invention* a central patron database (CPDB) 
5 comprising customer accounts from all of the casino properties is supported on a central LAN 
that is coupled to the casino LANs through the WAN. In this embodiment, the management 
system may be a single, centralized system supported on the central LAN. a distributed system 
comprising local management systems associated with each casino LAN. or a hybrid system 
including both centralized and distributed components. The preferred configuration for the 

m management system will depend on the data capacity of the WAN and the sizes of the various 
casino properties. The CPDB stores information about each customer. A customer's worth may 
be establisned in the CPDB as status data indicating the status of the customer. The status of the 
customer may be based on accumulated points that a customer earns from betting and other 
activity at the various casino properties or from a theoretical win profile of the customer. Each 

15 casino may also maintain a local database of-customer accounts, including the status data based 
on points earned at the casino or a locally generated theoretical win profile. 

In operation, a customer presents an identity card to a card reader when initiating a 
gaming or non-gaming activity. The system recognizes the customer from the identity card and 
obtains customer data of the customer from the CPDB or from a local database, including data 

20 indicating the customer's status. The present invention then provides enhanced physical 
instrumentalities to the customer based on the customer's status. 

There are many different types of physical instrumentalities that may be provided to the 
customer to enhance his or her experience at the casino. For example, when a valuable customer 
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is recognized at a slot machine, a highly visible light on top of the slot machine may be activated, 
thereby alerting both casino employees and other customers that this valuable customer is 
present. Differentiation of the customer in this manner also enables the casino to provide 
distinguished services to the customer, such as improved food and beverage services, and slot 
change or slot fill services. 

Another example of an enhanced physical instrumentality is the activation of a telephone 
installed near a gaming machine being used by the customer. This allows the valuable customer 
to make telephone calls without leaving the gaming machine, as other customers would have to 
do. Yet another example is the activation and enabling of a lockable storage compartment at the 
gaming machine to allow the customer to store personal items therein. Finally, yet another 
example of enhanced physical instrumentality is the automatic unlocking of a door to a 
privileged facility, such as a VIP club, when the customer's card is recognized and the 
customer's status or worth suitably determined. N 

It will be appreciated that the present invention differs from conventional fee-based 
membership systems and point-based systems, in that it provides activation of physical 
instrumentalities directly based on recognition of a customer* s status, and hence worth, from use 
of the customer's identity card. Unlike prior systems, in the present invention customer status is 
based on the customer's worth directly, and thus as the customer's worth increases due to the 
customer's gaming activity, then access or activation of the physical instrumentalities is 
provided. Also, conventional systems do not provide immediate activation of physical 
instrumentalities that directly enhance the customer's gaming experience. 

The term "affiliated casinos'*, as it is used throughout this disclosure, is intended to 
indicate any of a number of different relationships between casino properties. For example. 
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casinos may be affiliated through common ownership by a parent company, they may be owned 
by different companies operating under a cooperation agreement, or they may be under contract 
with the same provider for customer tracking services. 

Brief Description of the Drawings 

Fig. 1 is an overview of a national customer recognition system in accordance with the 
present invention. 

Figs. 2A. 2B. and 2C are block diagrams of the various system modules supported in the 
central database server and a casino property LAN, respectively, for different configurations of 
the customer recognition system. 

Fig. 3 is an overview of a casino LAN, indicating connections between the various input 
devices and distributed management systems supported on the casino LAN. 

Fig. 4. is a flow chart representing a method for tracking customer activity across all 
affiliated casino properties in accordance with the present invention. 

Fig. 5 is a block diagram of the system modules supported on casino LANs where a 
distributed patron database and management systems are employed. 

Fig. 6 is a block diagram of a network system incorporating a messaging system in 
accordance with the present invention. 

Fig. 7 is a block diagram of the messaging system for the network system shown in Fig. 

6. 

Fig. 8 is a block diagram of the components of a service application supported by 
transaction services of the open system network. 

Fig. 9 is a block diagram showing the relationship between the ASCII Definition File and 
the defined data structures and data dictionaries generated from the ASCII Definition File. 
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Fig. 10 is a representation of an ACDS defined data structure for communications 
between an RPG application and the messaging system of the present invention. 

Fig. 1 1 is a more detailed block diagram of the service application of Fig. 8. 

Fig. 12 is a block diagram of the network system of Fig. 6, including a security service in 
the gateway server. 

Fig. 13 is an illustration of a slot machine with a selectively activateable light and 
telephone features. 

Fig. 14 is a block diagram of the slot machine in accordance with the present invention. 
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Detailed Description of the Invention 

The present invention is described in detail for a configuration of the national customer 
recognition system comprising a central patron database (CPDB) on a central LAN that is 
coupled to local management systems associated with each casino LAN. This configuration is 

5 particularly useful for companies that have already invested significant capital in local 
management systems for their casino properties, because it leverages these systems into a 
company-wide network through the addition of a CPDB. The system configuration employing a 
centralized management system with a CPDB and the system configuration employing 
distributed management and database systems are discussed in conjunction with Figs. 2C and 5, 

m respectively. 

Referring first to Fig. I, there is shown an overview of a computer network 100 for 
implementing the system and method of the present invention. Computer system 100 is shown 
comprising a central database LAN 1 10 and casino LANs 120(l)-120(n), each of which is 
associated with one of the affiliated casino properties. Central database LAN 110 and casino 

is LANs 1 20( 1 )- 120(n) are coupled through a wide area network (WAN) 1 02. Typically, central 
database LAN 1 10 will be located at a central facility of the casino company. 

In the following discussion. LAN 120 designates any one of casino LANs 120(l)-120(n) 
unless otherwise noted. Similar notation, i.e. unindexed reference numbers, is used for the 
various components of LANs 120(1 )-120(n). It is understood that in a typical application, 

20 computer system 100 includes one or more LANs 120 for each casino property affiliated with the 
parent casino company, and all LANs 120 communicate with central database LAN 1 10 through 
WAN 102. This configuration allows each LAN 110, 120 to operate in a substantially 
independent manner until it requires access to data available on a different network. 
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In the disclosed embodiment central database LAN 1 10 comprises an Ethernet 106 to 
which a central database server 1 12 and a marketing support server 1 14 are connected. An 
optional server 1 16 on LAN 1 10. supports a centralized management system (CMS 284, Fig. 2C) 
in the fully centralized configuration of the national customer recognition system. A token ring 
5 108 is also shown connecting Ethernet 106 to WAN 102. Token ring 108 typically includes 
additional nodes, such as workstation 1 1 8. for marketing and local processing. Central database 
server 112 includes a central patron database (CPDB 220, Fig. 2A), comprising customer 
accounts based on data originating at each casino property affiliated with the company. For the 
embodiment employing distributed management systems (CMS 234. Fig. 2B). central database 
m server 1 1 2 is the only essential node on LAN 1 1 0. However, it is likely that in most 

implementations, other nodes such as workstations 1 18 and marketing support server 1 14 will be 
available for marketing analysis using data derived from CPDB 220. 

In the preferred embodiment of the invention, marketing support server 1 14 includes 
customer data from CPDB 220 stored in a manner that facilitates its use for marketing purposes. 
is For example, customer data may be sorted and stored in server 1 14 according to customer groups 
segmented by profitability, principal gaming location (property), or other marketing criteria. On 
the other hand, customer data in server 1 12 is stored in a manner that facilitates rapid access by 
customer ID or name. 

Referring now to Fig. 2A. there is shown a block diagram of various systems supported 
20 on central database server 1 12. These include an operating system (OS) 212. a database 

management system CDBMS) 214. a transaction management system 216'. and central patron 
database (CPDB) 220. Transaction management system 216' supports messaging between casino 
LANs 120 and services on central LAN 1 10. such as CPDB 220, allowing them to exchange data 
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as necessary. In the disclosed embodiment central database server 1 12 is an NCR 3555 
computer. OS 212 is UNIX SVR4. DBMS 214 is Informix 7.1. and transaction management 
system 216* is TOP END. available from AT&T/NCR. Central LAN 110 employs TCP/IP 
communication protocol for communications among the nodes of Ethernet 106 and token ring 
108. 

Referring again to Fig. 1, each casino property LAN 120 is shown with the same basic 
structure. For purposes of illustration. LAN 120 is shown comprising a token ring 122 to which 
are connected computers 124. 144, 154, a gateway server 126. and workstations 128. 148. Dumb 
terminals 132 and PCs 172. which are connected directly to computer 124. are typically 
associated with gaming tables (Fig. 3). and slot machines 130 are coupled to computer 124 
through a slot computer 154 and token ring 122. Thus, all gaming-related activity is routed to 
computer 124. At the selected computers, terminals and PCs, are coupled card readers 724 for 
reading a customer's identity card. In addition, computers 124, 144, 154 or PCs 172 coupled to 
card readers 724 may be located at other locations at the casino property, such as hotel check-in, 
restaurants, entertainment facilities, privileged facilities, and any other location at which it is 
desirable to recognize a customer via their identity card and provide some form of enhanced 
service or activation of a physical instrumentality that distinguishes the customer from other 
customers based on the customer's worth. 

A person skilled in the an will recognize that LANs 120 associated with different 
properties may vary from this structure in order to accommodate special needs at different casino 
properties, without altering the nature of the present invention. For example, a casino property 
lacking a hotel or event venue would not include computer 144 or workstation 128 and their 



-10- 



19538/03262/746756 



associated lodging and event management systems, respectively. In addition, other LAN 
protocols, including Ethernet and the like, may be used instead of token ring 122. 

Referring now to Fig. 2B. there is shown a detailed block diagram of LAN 120, 
indicating a casino management system (CMS) 234. lodging management system (LMS) 238, 
and event management system (EMS) 240. associated with various LAN nodes (computers 124, 
144, and workstations 128, respectively), for monitoring, tracking, and controlling different areas 
of casino operations. In a preferred embodiment of the invention. CMS 234 includes Report 
Program Generator (RPG)-based programs for on-line transaction processing (OLTP) 
applications. These applications consolidate activity data at the casino property related to 
gaming, and access CPDB 220 to retrieve or store data, as necessary. For example, dumb 
terminals 1 32 and PCs 1 72 communicate customer gaming activity data from gaming tables to 
CMS 234. Dumb terminals 132 and PCs 172 may also be used for tracking customers' currency 
and marker transactions and for accessing gaming activity that is tracked through a slot computer 
154. 

Automatic bet tracking at slot machines 130 is monitored by a slot monitoring system 
(SMS) 262 on computer 154. which couples accumulated bet tracking data to CMS 234 through 
token ring 122. In the preferred embodiment, bet tracking is accomplished through a card reader 
724 associated with slot machines 130, other gaming machines, or gaming table 134. (For the 
purposes of this disclosure, examples regarding bet tracking and customer recognition will be 
made with reference to slot machines 130, however it is to be understood that the same principles 
of operation of the present invention apply to any other type of gaming machine or gaming 
table.) 
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A customer inserts his or her identity card in the card reader 724 to initiate bet tracking 
and removes it to terminate bet tracking. When a customer inserts the identity card into the card 
reader 724, the SMS 262 sends a message to the slot machine 130 with information retrieved 
from the CPDB 220 or a local database in CMS 234. indicating various customer data, such as 
s the customer's name, account number, total points accumulated in the customer's account, the 
customers status, and the like. The slot machine 130 may display some of this information to 
the customer, such as the point balance. The slot machine 130 may selectively activate some 
physical instrumentality near the machine based on the customer's status data, which physical 
instrumentality distinguishes the customer from other customers and preferably enhances the 

w customer's gaming experience. A customer's betting activity at slot machine 130 or the like is 
accumulated in SMS 262 until the session is terminated or an account status is requested by CMS 
234, at which time the data is transferred to CMS 234 via LAN 120. 

LAN 120 may optionally include a pit tracking system (PTS) 258 to automatically track 
customer activity at gaming tables 134. PTS 258 is shown supported on a computer 174, which 

is couples customer activity data to CMS 234 through LAN 120. PTS 258 uses card readers 724 
associated with player positions at gaming tables 134 to track customers' betting activity. 
Estimates of betting activity are based on a customer's time at a gaming table and the minimum 
bet at the table. Systems for automatically tracking betting activity at slot machines and gaming 
tables are well known in the art and are not described in greater detail here. 

20 In the preferred embodiment of the invention, a lodging management system (LMS) 238 

is maintained on computer 144. However, there is no reason that CMS 234. LMS 238 and any 
other management systems could not be supported on the same computer or some different 
combination of computers. LMS 238 comprises the software necessary for managing hotel 
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operations within the casino, including reservations, room service, and other activities associated 
with hotel operations. In a preferred embodiment of the invention. LMS 238 communicates with 
CMS 234 to search locally for selected customer information available on that system. However. 
LMS 238 may include its own local database for customer data. Where a terminal or computer 
providing LMS 238 access is located, such as at a hotel front desk, card readers 724 may be 
located to allow a customer's identity card to be read, the customer recognized, and provided 
with distinguished services if appropriate. 

Also shown in Fig. 2B is an event management system (EMS) 240 on workstation 128 
and a restaurant/retail point of sale system (POS) 244 coupled to workstation 148 and card reader 
724. EMS 240 comprises software for handling ticketing information, reservations, and sales. 
POS 244 comprises accounting software for operating restaurants and retail venues within the 
casino property as well as software for transmitting charge information to other management 
systems. For example, data relating to meals charged to rooms or redeemed meal comps are 
coupled from POS 244 to LMS 238 and CMS 234, respectively, through LAN 120. 

The primary role of gateway server 126 is to provide a link between selected nodes of 
LAN 120 and central database server 1 12 through WAN 102 and LAN 110. For this purpose, 
gateway server 126 includes a LAN/WAN interface 280 that couples data packets between the 
communication protocols of LAN 120 and WAN 102 and another instance of transaction 
management system 216 that routes data packets between management systems 234, 238, 240 
and selected services in CPDB 220. In the preferred embodiment of the invention. CMS 234 on 
computer 124 accesses CPDB 220 through transaction management system 216'. 216, while 
LMS 238 and EMS 240 access CPDB 220 through CMS 234, as discussed below. An interface 
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module 235 in CMS 234 provides communication links with transaction management system 
216, as discussed below. 

In the disclosed embodiment of the invention, computers 124, 144 are IBM AS/400 
computers, computer 154 is an IBM RS6000. gateway server 126 is an NCR 3410. workstations 
128, 148 are based on '486 or better processors, and transaction management system 216, 216' is 
AT&Ts TOP END. WAN 102 employs TCP/IP. an open communication protocol, while LANs 
120 employ an IBM communication protocol. LU6.2. LU6.2 allows direct communication 
between LAN nodes, but it is not the preferred protocol for communications on WAN 102. In 
the preferred embodiment of system 100. LAN/WAN interface 280 includes the software 
necessary to couple message packets between LU6.2 and TCP/IP protocols for communications 
between central LAN 1 10 and casino property LANs 120. In particular. LAN/WAN IF 280 
operates in conjunction with transaction management system 216. 216' to provide CMS 234, 
LMS 238, and EMS 240 with rapid access to customer accounts for all customers who have 
visited any casino property affiliated with the casino company and obtained a customer ID card. 
For this purpose, each customer ID card includes a unique ID number that is associated with a 
customer account in CPDB 220. 

In the preferred embodiment of the invention, the RPG applications of CMS 234 are 
implemented in the AS400 environment of computer 124. In order to facilitate fasu real-time 
communication between CMS 234 and CPDB 220. a messaging system is implemented as part 
of interface module 235 of computer 124 and transaction management system 216* of server 1 12. 
The messaging system functions as an application program interface (API) that allows the RPG 
applications of CMS 234 to communicate with CPDB 220 via transaction management system 
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216. 216'. with LAN/WAN interface 280 coupling messages between the different 
communications protocols. 

In the preferred embodiment of system 100, customer data is transferred between LAN 
1 20 and LAN 1 10 by means of message packets comprising header and data segments, the 
attributes of which are specified in a data dictionary associated with the messaging system. The 
data segments reflect the database schema of CPDB 220 and the header segments correspond to 
user provided service applications (not shown) accessed through transaction management system 
216. These user provided service applications implement functions for coupling data to and from 
CPDB 220 in response to requests from CMS 234. A utility associated with the messaging 
system reads the data dictionary and defines data structures in the AS400 system environment 
suitable for passing data between the RPG applications of CMS 234 and the messaging system. 
A message building/parsing module uses data provided through the defined data structures to 
build message packets for transmitting requests to transaction management system 216, 216', 
which directs the request to the appropriate service application. A message building/parsing 
module associated with the service applications provides analogous services for communications 
with DBMS 214. The messaging system is described in greater detail below with respect to Figs. 
6-12. 

As noted above, the optimal architecture for system 100 will be determined in part by the 
volume of data traffic that WAN 102 can handle, i.e. the "bandwidth" of WAN 102. The 
embodiment of Figs. 1, 2A, and 2B, in which each casino LAN 120 includes CMS 234 for 
handling day to day transactions and communicating data to CPDB 220, balances the advantages 
of centralized computing systems with the bandwidth limitations of typical WANs 102. Where 
WAN 102 has sufficient bandwidth to handle real-time data transactions between CPDB 220 and 
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a plurality of casino properties, local CMS 234 at each of the plurality of casino properties may 
be eliminated in favor of a centralized CMS 234 implemented on central LAN 110. 

Referring now to Fig. 2C there is shown a simplified block diagram of an alternative, 
centralized configuration for system 100. In the configuration of Fig. 2C, local CMSs 234 
associated with selected casino LANs 120' have been eliminated in favor of a central CMS 284 
supported on server 1 1 6 on central LAN 110. In this embodiment of the invention, each casino 
LAN 120' includes one or more computers 124' for communicating with central CMS 284 over 
WAN 102. Since computers 124* merely provide access to central CMS 284. they may be 
workstations or PCs. Central CMS 284 handles day to day transactions for each of casino LANs 
120'. maintaining a separate data store for each LAN 120* under its management The data stores 
of central CMS 284 for LANs 120' are periodically updated to CPDB 220 to maintain the 
centralized data current. Where the data capacity of WAN 102 is sufficiently, it may be possible 
to eliminate local CMS 234 from all LANs 120, 120*. Similar hybrid and fully centralized 
configurations may also be set up for LMS 238 and EMS 240. 

Another alternative to the configurations of Fig. 2A. 2B. and 2C is a fully decentralized 
configuration in which CPDB 220 is eliminated in favor of a distributed database. This 
configuration is discussed in greater detail in conjunction with Fig. 5. Unless otherwise 
indicated, the following discussion assumes system 100 is configured as indicated in Figs. 2A 
and 2B. 

Referring now to Fig. 3, there is shown the embodiment of system 100 including CPDB 
220 and local CMS 234, with communications links between different nodes explicitly indicated. 
In the disclosed embodiment, for example, CMS 234 receives customer activity input directly 
from gaming tables 134. kiosks 136, restaurants or privileged facilities 133, and a customer 
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information center 138. CMS 234 also receives customer activity data from slots 130 through 
SMS 262. Kiosks 136 are terminals located around the casino property that allow customers to 
check on their activity points or comp availability by inserting their customer ID cards. 
Customer information center 138 provides services to casino patrons such as membership 
5 information and arranging for "comps", as described in detail below. CMS 234 also provides 
data to each of these input devices. For example, casino employees at gaming tables 1 34 receive 
customer data summaries so they can determine whether the customer qualifies for a "comp" or 
simply greet the customer by name. 



io provides customer account summaries to these locations for use by casino employees. EMS 240 
also exchanges customer data with reservations clerks 176 and. in addition, exchanges customer 
data with events venues 1 74. 

In the disclosed embodiment, both LMS 238 and EMS 240 communicate with gateway 
server 126 through CMS 234, and gateway server 126 handles the data translation necessary to 

15 communicate with CPDB 220 via WAN 102. This communication topology facilitates searching 
among different management systems 234. 238. 240 for customer data, but it is not essential to 
the present invention. The same system could be operated with EMS 240 and LMS 238 
communicating with gateway server 126 directly. In addition, where UNIX-based casino, 
lodging, or event management systems are available, they may communicate directly with WAN 



20 102. 

Also shown in Fig. 3 is a teleservices module 298 coupled to CPDB 220 through WAN 
102. Teleservices module 298 represents a telephone-based system that allows customers to 
arrange travel plans at some or all of the affiliated casino properties. By connecting teleservices 




LMS 238 receives customer data from a hotel desk 178 and reservations clerks 176 and 
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module 298 to WAN 102. operators can access customer data in CPDB 220 in real-time. This 
allows operators to determine, for example, whether a customer arranging a trip to one of the 
affiliated casino properties qualifies for a comp room, a room upgrade, or the like. 

Customer accounts in CPDB 220. and in the local database of the CMS 234. include 
detailed information on the customer's preferences, interests, credit rating, win profiles, and 
accumulated activity points. Each customer account also includes at least one field for indicating 
the status of the customer. In one embodiment, the status field may indicate a customer's status 
as special status customer or a non-special status customer. Special status customers include for 
example, "VIP" customers, and members of exclusive programs or clubs maintained by the 
casino. In a preferred embodiment, the status field is a Boolean which is used to indicate 
whether or not the customer is a "Premier'* guest a particular type of special , status customer. 
The status of a customer preferably reflects the customer's worth to the casino, and is determined 
as a function of the customer's betting activity. In one embodiment, the customer's status is a 
function of the customer's theoretical win value to the casino. In another embodiment, status is a 
function of total accumulated points in the customer's account. In yet another embodiment, 
status is a function of both theoretical win and accumulated points. In one embodiment, 
theoretical win values and points are determined according to gaming data accumulated at any of 
the casino properties affiliated with the parent company through input devices such as slot 
machines 130 and dumb terminals 132 associated with gaming tables 134. In another 
embodiment, theoretical win and points are based on gaming data accumulated at a single casino 
property. Activity points are determined in part by gaming activity but may also be augmented 
by sweepstakes and various other promotional programs. Other customer data relating to non- 
gaming activity may be tracked through various input devices, including workstations 128, 148 
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supporting EMS 240 and POS 244. and made available to the marketing department for 
evaluation and analysis. 

in order to provide rapid access to essential customer data while minimizing data storage 
requirements for casino properties, each CMS 234 maintains accounts for regular customers in a 
local database. With this configuration. CMS 234 accesses CPDB 220 whenever a customer 
registers activity in any of the casino venues and no customer account data is available locally. 
For example, when a customer presents his or her identity card to check into the hotel at the 
casino property, LMS 238 checks with CMS 234 for a local customer account. Currently, LMS 
238 does not maintain a local data store, but if expanded to do so, LMS 238 would check its local 
data store before checking that of CMS 234. 

In general, customer data may already be available locally from CMS 234 if the customer 
has visited the casino property before or if. for instance, a new customer played slot machines 
130 before checking in to the hotel. In the first case, static customer data, including the 
customer's name, address, credit rating and the like, would be maintained in CMS 234 from the 
previous visits. In the case of a new customer. CMS 234 will have already retrieved a summary 
of the customer's account data from CPDB 220. as described below, and LMS 238 may access 
the data from CMS 234. 

If the customer data is not available locally, as when a customer new to the casino 
property checks into the hotel first, LMS 238 will send a data request to CMS 234, which 
forwards it to CPDB 220 using the messaging system and transaction management system 216, 
216*. This transaction is carried out on-line in order to provide rapid access to a summary of 
basic customer information such as the customer's address, credit status, gaming points, 
theoretical win profile, and recent trip activity. Ready access to this customer data allows casino 
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employees to make the check-in process both more efficient and more personalized for the 
customer, enhancing the customer's overall experience and making him or her more likely to 
return. 

Throughout the customer's stay at the casino property, the customer's account will be 
updated to reflect the customer's activities at the various casino venues. For example, when the 
customer inserts his or her identity card into a card reader 724, such as at slot machine 130 or 
gaming table 1 34, the account number is read, the customer's betting activity is monitored, and 
the customer's account updated to reflect the activity, including updating of the customer's 
status. Similarly, if the customer purchases an event ticket or redeems customer activity points 
for a meal, workstations 1 18, 148. respectively, provide the ID number and transaction data to 
CMS 234. which updates the customer account to reflect the transaction. LAN 120 thus allows 
all of the customer's activity at the associated casino property to be tracked, which in turn 
provides a more accurate picture of the customer's value to the casino. 

The cross-property nature of system 100 makes the accumulated customer data available 
at whichever casino property the customer decides to visit. In order to maintain all account data 
up to date, all data processed by local management systems CMS 234, LMS 238. and EMS 240 
is periodically updated to CPDB server 1 12 in a batch process. This update synchronizes data in 
all storage locations, i.e. CPDB 220 and local databases associated with CMSs 234, to ensure 
that employees at any casino property have access to the latest data. When this configuration is 
employed with a WAN 102 having limited bandwidth, data synchronization is typically done 
when traffic on WAN 120 is low. in order to minimize any interference with on-line data access 
transmissions. 
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Data must also be synchronized in the configuration of Fig. 2C with central CMS 234 
periodically updating CPDB 220 from the data stores associated with LANs 120\ However, data 
traffic generated by these updates is limited to central LAN 120 and does not impact the data 
traffic on WAN 102. 

The seamless flow of data supported by the present invention reinforces the customer's 
perception of the national brand associated with the parent company and the activity point system 
provides additional incentives for the customer to patronize the casino s properties in different 
locations. In the absence of the method of the present invention, there is no record of the 
customer's activities at other casino properties and, consequently, there is no opportunity to 
leverage the data already accumulated on the customer to affirm the corporate links between the 
properties. 

Referring now to Fig. 4, there is shown a flow chart of method 400 in accordance with 
the present invention for tracking customer activity data and accumulating activity points across 
casino properties. For purposes of illustration, the discussion assumes that the customer activity 
data is being directed to CMS 234. i.e. gaming activity of some sort is being tracked. Method 
400 is initiated when a triggering event, such as insertion of an ID card into a slot machine 130 or 
entry of an ID number or name into a dumb terminal 1 32 is detected 410. The customer ID 
number (or name) is read 420 by CMS 234, which determines 430 whether it has already 
activated the associated customer account. If the account has not yet been activated by CMS 234 
at the current casino property, the customer account is activated 434 in CMS 234, a request for 
summary data from the customer's account is forwarded 438 to CPDB 220 and the activated 
account is updated 442 with the summary data from CPDB 220. If, on the other hand, it is 
determined 430 that an account is already activated, the summary data is already available and 
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the customer account is thereafter updated 444 to reflect any new activity. In either case, the 
status of the customer is also determined 431, and if the customer is a special status customer, a 
physical instrumentality proximate the customer is activated 433 for the customer's benefit. 

It is noted that in the centralized configuration of system 100 (Fig. 2C). central CMS 284 
5 maintains data stores for each LAN 120 it handles. Consequently, the checking process 
described above occurs with centralized CMS 284 as well. 

Gaming and non-gaming activities are treated differently, and updates occurring at step 
444 typically include non-wagering activities related to gaming. For example, a customer's 
account may be updated at this point to reflect redemption of activity points, redemption of a 

m comp voucher, or currency or marker transaction (credit advance). In addition, some wagering 
related data may be updated 444 at this time. For example, the start time of a betting session or 
the venue at which a wagering activity is occurring may be reflected to the customer's account 

As noted above, activity point awards are based on a number of criteria and these may be 
adjusted to target different casino properties or venues. In addition, the number of points 

15 awarded for an activity may be a function of the status of the customer as determined at step 43 1 . 
At step 448. method 400 determines whether the monitored activity is one for which any points 
are awarded. In the preferred embodiment of the invention, non-gaming activity, such as hotel 
and event activity, may be tracked for accounting and marketing purposes. Once non-gaming 
activity has been reflected in the customer account, method 400 returns to await 410 the next 

20 triggering event. 

In the current embodiment of the invention, points are awarded for gaming activities, but 
this may be readily expanded to include point awards for non-gaming activities. With respect to 
gaming activities, points awards are determined when the activities are completed or an account 
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status is requested. For example, when a customer initially inserts an identity card into a slot 
machine 130. method 400 will be triggered 410 to record the event However, the activity points 
awarded are based in pan on how much the customer wagers, and this is not determined until the 
customer removes his or her card from the slot machine 1 30 or an update request is received by 
SMS 262. If the current triggering event is, for example, a card removal or status request, the 
customer account is updated 450. Otherwise, method 400 returns to step 410 to await the next 
triggering event For this reason, SMS 262 (Fig. 1, 2B) maintains betting data until one of these 
events trigger it to forward the data to CMS 234 for updating the appropriate customer account. 

Referring again to Fig. 4, points are updated 450 when a betting session is completed or 
an account status requested, and method 400 checks 452 a table to determine the number of 
points to be awarded. For example, the company may promote a new casino property by 
awarding bonus points for all gaming activities at the new property, or the casino may award 
bonus points for gaming at a new venue that is being promoted. In any case, method 400 
determines 452 the appropriate point level and adjusts 454 the point tally in the customer's 
account accordingly. 

Betting activity is also reflected 458 in a separate field for purposes of determining a 
customer's comps. Unlike activity points, comp data is based solely on the historical amount of 
wagering done by the customer and does not reflect point weighting or other promotional 
schemes. When any point and comp adjustments have been made, method 400 returns to await 
410 the next triggering event 

CPDB updates 460 are required to synchronize data in the embodiment of system 100 
employing distributed CMSs 234 and centralized CMS 284 (Figs. 2A and 2B. and Fig. 2C 
respectively). In the former configuration, these updates periodically transfer accumulated data 
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from all accounts in local management systems (typically. CMS 234) to CPDB 220. In the 
preferred embodiment of this configuration, updates to CPDB 220 are scheduled at least once 
every twenty four hours at time periods when activities on casino LANs 120, central LAN 1 10, 
and WAN 102 are low. Where WAN 102 has a high bandwidth, data updates may be made 
without regard to other traffic on WAN 102. For the reasons discussed above, CPDB updates 
from the data store of central CMS 284 do not impact data traffic on WAN 102 and may be 
scheduled more flexibly. 

Method 400 balances the casino company's need for rapid on-line access to customer 
information from all of its casino properties with the personnel and monetary costs of 
maintaining multiple large databases. Instead of duplicating all customer accounts at all casino 
properties, copies of a customer's account are maintained only on central database server 1 12 and 
in databases of CMS 234. CMS 284 associated with those casino properties visited by the 
customer. On the other hand, the data is available from central database server 1 12 whenever it 
is requested by another casino property. In the preferred embodiment of the invention, static 
customer data is maintained on local CMS 234 for a period of between six months and two years, 
depending on each casino's policy. If no activity is registered by a customer during this period, 
the local account may be purged. 

Computer system 1 00 and method 400 provide the infrastructure for a national customer 
recognition program for attracting and retaining customers. They also provide the raw customer 
data on which the casino company can base its marketing decisions and through which the 
company can launch new marketing programs. 

Customer recognition awards may be based on different subsets of customer data 
accumulated through and stored on system 100. The customer recognition program based on 
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activity points has already been mentioned. A customer accumulates points in his or her 
customer account according to his or her activity at all venues of all casino properties and 
according to any promotions currently being run by the casino or its parent company. The 
accumulated points represent a monetary value associated with the customer's activities and may 
be used in place of cash within any of the affiliated casinos. Thus, in addition to the already 
noted benefits of the point system, it contributes to the establishment of a cashless, paperless 
business environment. 

In order to provide an incentive for customers to accumulate points, points may be earned 
at any casino property affiliated with the company. The cross-property nature of point 
accumulation encourages customers to visit casino properties affiliated with the parent company 
when they travel, since this activity contributes to their rewards no matter which casino property 
is the source of the points. Point awards may be structured in a variety of ways to target specific 
activities. For example, bonus points may be awarded to customers who visit at least two 
affiliated casino properties within a given time period. Point awards may also be based on a 
tiered system, under which customers accumulate points for their gaming activities at rates that 
increase as their point totals increase. In general, point awards may be instituted for different 
time periods and for different properties, according to the marketing goals of the casino and the 
parent company. 

Accumulated points may also be redeemed at any casino property affiliated with the 
casino company. Using system 100.. a casino employee can call up data indicating the 
accumulated points of any casino customer, regardless of the property at which the points were 
earned and regardless of whether the customer is a regular at the casino property. For example, a 
customer who has been accumulating points through regular visits to a Las Vegas casino can 
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visit an affiliated casino in New Jersey and redeem his or her accumulated points for goods or 
services at the New Jersey casino. 

Point awards also encourage customers to use their ID numbers at any of casino venues 
of the affiliated casino properties that offer customer tracking. This enhances customers' interest 
s in participating in tracking programs and provides the casino company with more data on which 
to base its marketing decisions. Thus, the point system can be used to both recognize customers 
for their patronage and to market different facilities of the company. 

Comping is another customer recognition program that is supported by system 100 and 
method 400. Comps are awarded to a customer according to the customer's average daily 
10 theoretical win, which is an estimate of the casino's average daily winnings from the customer. 
The level of comps available to a customer is based on the casino's theoretical win from different 
gambling activities and the customer's historic level of these gambling activities. For example, 
on average a casino will win a statistically determinable amount of money, i.e. the theoretical 
win, from a customer who bets an average of $5000 per trip on blackjack. If the customer's 
is theoretical win profile is large enough, the casino may "comp" the customer a free night's 
lodging, allowing the customer an additional day of gaming. Customer betting activity 
accumulated by system 1 00 is crucial to comping customers at a level commensurate with their 
expenditures, since it provides the raw data on the customer's betting activity. 

Casino employees have some discretion in awarding comps and the practice may vary 
20 from one casino property to another. System 100 helps eliminate some of the vagaries 
introduced by the discretionary nature of comping by providing the same customer data to 
employees at ail casino properties visited by a customer. This ensures that comping decisions 
will at least be based on consistent estimates of the customer's average theoretical win profile. 
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Regular customers at one casino property of the company who visit a new casino property of the 
company are more likely to be "comped" at a level consistent with their play at their regular 
casino property. The national character of the present tracking system also means that the 
average daily wager figure will include a larger number of data points, since the customer's 
5 gaming activities at all casino properties are included. Estimates based on this data should be 
that much more accurate. 

Customer data accumulated by system 100 is also used in tracking customer offers to 
determine the validity of outstanding offers and the profitability of those offers for the casino. 
These offers can be entered into a customer's account to indicate their availability to the 

in customer, and the customer's account can be updated as necessary when an offer is redeemed. In 
addition, data accumulated in CPDB 220 during the visit in which the customer redeems the 
offer can be used 10 determine whether or not it is profitable for the casino to repeat the offer or 
make additional offers. For example, the casino may send to selected customers offers for a free 
nights lodging at one of its properties if the customer stays for at least two nights. In certain 

is cases, the customer's incremental expenditures for the extra day's stay may not justify repeating 
the offer to that customer. Information gathered on customer activity associated with an offer 
may also allow the marketing department to better target their offers. 

Referring now to Fig. 5, there is shown a simplified block diagram of an alternative 
embodiment of system 100. in which both management system processing and database 

20 operations are distributed among LANs 120. This embodiment is illustrated using four LANs 
120(1)-120(4) coupled to WAN 102. but the number of LANs 120 may be greater or less than 
this. 
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LANs 120(1 VI 20(4) include local CMS 234(1 )-234(4). respectively, each of which has 
an associated local database. The local databases of CMS 234(1) - 234(4) form the distributed 
database for this embodiment of the present invention. Each local database comprises a local 
guest master list for the corresponding casino property and a local cross-reference list that 
includes selected customer data from every other affiliated casino property. For example, the 
local guest master list of CMS 234(1 ) comprises data for all casino customers who received their 
identity cards at the associated casino property (property 1). The local cross-reference list of 
CMS 234(1) includes data sections for properties 2, 3, and 4. which comprise customer data for 
any customer that received their identity card at property 2, 3, or 4, respectively, and 
subsequently visited property 1 . CMS 234(1) also includes virtual files 2. 3, and 4 for properties 
2, 3. and 4, respectively, through which data on customers who are not listed in either the local 
master list or local cross-reference list may be accessed. In effect virtual files 2, 3, 4 on CMS 
234(1) represent local master lists residing on CMS 234(2), CMS 234(3), and CMS 234(4), 
respectively, that are accessed by CMS 234(1) through WAN 102. 

In this embodiment of the invention, a customer of a casino is assigned an identification 
number including a property field that indicates the casino at which the customer's account 
originated, i.e. where the card was issued. When a customer of property 1 uses his or her card at 
property 1, the property field indicates to CMS 234(1) that the customer's account data is 
accessible through the local master list of CMS 234(1 ). On the other hand, when this customer 
visits property 3, the property field signals that CMS 234(3) should check the data segment 
associated with property 1 in the local cross-reference list for the customer's account. If it is the 
customer's first visit to property 3, there will be no account data in the property 1 data segment of 
the local cross-reference list and CMS 234(3) will use virtual file 1 to access the local master list 
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of CMS 234(1 ). When the data is retrieved from CMS 234(1), it is stored in the property 1 data 
segment of the local cross-reference list of CMS 234(3). where it is updated with the customer's 
activity during his or her visit to property 3. 

In the system of Fig. 5 ? where a distributed database configuration is employed, data 
synchronization is particularly important to ensure that all activity data, including points and 
comp availability, is reflected in a customer's account and is available at any of the affiliated 
casino properties. For example, when a customer from property 1 visits property 3, the data on 
the customer's activity at property 3 is added to his or her account in the property 1 segment of 
the local cross reference list of CMS 234(3). Data synchronization ensures that this new data, 
including points or comps that are earned or redeemed during the visit is available when the 
customer visits any other property. Synchronization may be accomplished in a number of ways. 
For example, the customer's accounts at each casino property may be periodically updated to 
reflect any activity recorded by the customer at any of the affiliated properties, so that each 
property visited by the customer has a complete set of the latest data. 

Alternatively, all changes to a customer's account on any guest master list may be 
periodically updated to the customer's principal account, i.e. the account at the issuing property. 
In this case, each visit to a different property requires updating of the customer account on the 
guest master list with the account data from the customer's principal account. Provided these or 
similar procedures are implemented to ensure the coherency of the distributed database, the point 
and comp system may be implemented in the manner described above. 

The present invention provides for the activation of various physical instrumentalities in 
response to recognizing the customer and determining the customer status encoded in the 
customer account. Referring now to Fig. 13, there is shown an illustration of a gaming machine 
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configuration 600 including exemplary physical instrumentalities that may be activated when a 
customer is recognized and the customer's status determined. One embodiment of the gaming 
machine configuration 600 includes a slot machine 130 that rests on cabinet 604. The slot 
machine 130 has a light 602 mounted at its top, which provide a highly visible, and selectively 
activateable lighted display. The cabinet 604 includes lockable interior compartment 614 with a 
solenoid-controlled lock 615 in the door thereof. When engaged, the solenoid (not shown) 
engages the lock 61 5 in a locked position so that the door to the compartment 614 cannot be 
opened, and the lock 615 cannot be used. When disengaged, the lock 615 is released and the 
door to the compartment 614 may be opened or closed: the lock 615 may then be used to 
manually lock the door to secure the compartment 614. In other embodiments, slot machine 130 
is replaced by other gaming machines, for example any of the numerous varieties of video or 
computer-based poker, slots, keno, gaming machines. Alternatively, the cabinet 604 (or a 
suitably structured variant thereof) may be provided in conjunction with a gaming table 134, 
such as part of a blackjack or other card table. 

In the illustrated embodiment, a backboard 610 extends from the back of the cabinet 604 
and includes a telephone mounting plate 608 with a standard RJ-l 1 telephone line jack (not 
shown). The mounting plate 608 receives a telephone 609 and couples it to a telephone line via 
the line jack. The telephone line jack is selectively activateable to allow selected customers to 
use the telephone 609. 

Referring to Fig. 1 4 there is shown a block diagram of the gaming machine configuration 
600 in accordance with the present invention. The gaming machine configuration 600 includes 
within the slot machine 130 a main processing unit (MPU) 702, a game monitoring unit (GMU) 
708. and direct drive relay board 714. The GMU 708 is a Bally Systems, Inc. computer board 
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that communicates with the SMS 262. In particular, the GMU 708 communicates betting data of 
the customer to the SMS 262. and receives from the SMS 262 message data pertaining to the 
customer, such as customer status information from the customer's account in the CPDB 220 or 
in the CMS 234 local database. The MPU 702 controls the overall functionality of the slot 
machine 602. The MPU 702 communicates with the GMU 708 via a connection between a 
communications port 706 and a plug in card 712. The GMU 708 includes direct drive plug in 
710 that couples to the direct drive relay board 714. The GMU 708 and MPU 702 are also 
coupled to a card reader 724 which reads an inserted customer identity card. 

The direct drive relay board 714 contains a number of relays 716. each of which controls 
a physical instrumentality proximate to the gaming machine configuration 600. In the illustrated 
embodiment, relay 716b is coupled to the light 606, relay 716c is coupled to the solenoid 720 
that controls the lock 61 5 for the interior compartment and relay 716d is coupled to the line jack 
623. The direct drive relay board 714 also includes logic to control the various relays 716 in 
response to control signals from the GMU 708. 

In accordance with the present invention, the gaming machine configuration 600 operates 
as follows to provide customer worth differentiation. When a customer inserts his or her identity 
card into card reader 724. the SMS 262 sends a message containing customer data, including 
status data, from the customer's account in the CPDB 220 or from a local database. This 
message is read by the GMU 708. If status data indicates a special status customer, the GMU 
708 sends an activate signal to the direct drive relay board 714. The direct drive relay board 714 
activates a designated relay 716 to activate one or more of the physical instrumentalities coupled 
to the relays 716. 
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In a simple embodiment where there is only a single type of special status customer, all 
employed relays 716 are signaled to activate their respective physical instrumentalities. In this 
embodiment, relay 716b is activated and energizes the light 602 on top of the slot machine 130. 
This alerts both casino personnel and other customers of the special status of the customer at the 
5 slot machine 130. Alerting casino personnel also allows these personnel to provide better service 
to the special customer, such as faster or more frequent food and beverage service, or faster slot 
changes. 

Also, relay 71 6c is activated, which controls solenoid 720, releasing the lock 615. The 
special status customer is now able to use the interior compartment 614. and manually lock it and 

m unlock it with a casino-supplied key. This enables the special customer to privately and securely 
store personal belongings at the slot machine 130. without fear of loss. 

Relay 716d is also activated, coupling the line jack 623 to the telephone line, and thereby 
activating telephone 609 for use by the customer. These various physical instrumentalities 
provide an enhanced experience to the special status customer, and thereby increase the 

is customer's sense of brand loyalty to the casino. In addition, these activated physical 

instrumentalities allow the casino to differentiate between customers based on their worth to the 
casino. 

In another embodiment where there are multiple categories of special status customers, 
then individual ones of the physical instrumentalities may be activated depending on the 
20 particular type of special customer. For example, a first type of special status customer may only 
have light 602 activated. A second type of special customer may have both the light 602 
activated and the lock 61 5 to the interior compartment 614 enabled. Finally, a third type of 
special customer may also have the telephone 609 also activated in conjunction with the light 
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602 and lock 615. In another alternate embodiment activation of selected ones of the physical 
instrumentalities may be based on the customer's point total in customer account, so that as 
higher point totals are reached, additional physical instrumentalities that enhance the customer's 
experience are activated. 

The physical instrumentalities described with respect to Figs. 1 3 and 14 are merely 
exemplary of a wide range of physical instrumentalities that may be activated on the basis of 
recognition of special status customers. The present invention entails the selective activation of 
physical instrumentalities at any location in or about the casino in response to status data 
indicating the status of a customer. Exemplary structural features to provide for identification of 
special status customers include a card reader 724. a control mechanism such as direct drive relay 
board 714, and a logic unit such as a GMU 708 that may be installed to control activation of the 
physical instrumentality. These structural features would be coupled to a LAN 120, a CMS 234 
or the like, and a CPDB 220. for example as described with respect to Fig. 2B. 

For example, the casino may have privileged facilities, such as member-only clubs, that 
are accessed by controlled doors, with any variety of computer-controllable locking mechanisms. 
The locking mechanism of such a door may be coupled to a relay 716 and a logic unit, which in 
turn are coupled to a card reader 724 located suitably near the controlled door. Insertion of the 
customer identity card initiates communication with the CMS 234 to obtain customer data 
including status data from the CPDB 220. If the customer status data indicates a special 
customer, the logic unit signals the controllable locking mechanism to unlock the doors and 
allow access to the privileged facility. 

In another embodiment of the present invention, distinguished services may be provided 
to the special status customer in conjunction with the activation of physical instrumentalities. 



-33- 



19538/03262/746756 



The variety of distinguished services will generally depend on the location of the customer in the 
casino property at the time the customer is recognized as a special status customer. A 
distinguished service is a service that is preferably provided only to special status customers and 
serves to enhance the customer's experience at the casino property. 

In one embodiment, the distinguished services are provided to a customer at gaming 
machines, such as slot machines 130. gaming tables 134. and the like following recognition of 
the customer as a special status customer. For a customer at a gaming machine or gaming table 
134, distinguished services include faster slot change to the customer, faster slot fills, and faster 
slot payouts, as compared to how these services are provided to non-special status customers. 
Other distinguished services include express or more frequent food or beverage service to the 
customer at the gaming machine or gaming table. One means by which these distinguished 
services are initiated is by a ligh; 602 situated proximate the gaming machine. When the light 
602 is activated upon identification of a special status customer, casino personnel who see the 
light 602, are immediately aware of the presence of the special status customer at the particular 
gaming machine having the light 602. Accordingly, these casino personnel can provide the 
distinguished services to the customer as needed. 

In other embodiments, distinguished services are provided to a customer who patronizes 
dining or entertainment facilities at the casino property. In these embodiments, card readers 724 
are placed near the entrance to these facilities, and are coupled to the LAN 1 20. and CPDB 220 
as described above. When the customer approaches the facilities, he inserts his identity card into 
the card reader 724. In the manner described above, the CMS 234 obtains the customer's 
account data from the CDPB 220 and determines the status of the customer. Where the customer 
is a special status customer, the customer is provided with a relevant distinguished service at the 
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facility. For example, distinguished services in this context include priority or preferred seating 
at the facility. Casino personnel at the facility may be apprised of the presence of the special 
status customer by activation of indicators on terminals 1 32 or computers 1 72 located at the 
facility. 

There has thus been disclosed a system and method for collecting customer data across all 
of the casino properties of a company, accumulating the collected data in a patron database, and 
making the accumulated data available at any casino property when triggered by a customer visit 
to the casino property. The system provides an infrastructure for implementing across all 
affiliated casino properties a point system that rewards customers for the gaming activities and 
allows targeting of different casino properties and venues for marketing purposes. The system 
also makes available to casino employees the same customer data, independent of which casino 
property the customer visits regularly. This allows customers to receive personalized service and 
to be rewarded in accordance with their value to the casino even when visiting new casino 
properties. 

Referring generally now to Figs. 6-12 there is shown an embodiment of the messaging 
system employed in the preferred embodiment of computer system 100 (Fig. 1). 

Referring first to Fig. 6. there is shown a block diagram of a networked computer system 
A 100 that includes a messaging system A 120 for communications between application programs 
on proprietary and open system platforms. Computer system A 100 comprises a first computer 
Al 12 based on a proprietary system architecture, a server A 192 based on an open system 
architecture, and a gateway server A 1 52 for connecting the different system architectures. The 
proprietary system architecture of first computer A 1 12 is represented by network protocol A 130, 
and the open system architecture of server A 192 is represented by network protocol A 160. In the 
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disclosed embodiment of system A 100. the open system architecture is UNIX. Windows, or the 
like, the network protocol A 160 is TCP/IP. the proprietary system architecture is IBM's System 
Network Architecture (SNA), and network protocol A130 is IBM's SNA LU6.2 

First computer A 1 12 includes an RPG application Al 1 0. messaging system A 120, and 
network protocol A 130. Messaging system A 120 acts as an application program interface (API) 
between RPG application Al 10 and a transaction management system A 150 on gateway server 
152. Transaction management system 150. in turn, provides access to transaction services A 170 
on open system server 192. Transaction services 1 70 represents the different services that may 
be accessed by RPG application Al 10 and the means for accessing these services. 

Gateway server A 152 includes a network services module A 140, transaction management 
system A 150, and an interface module A 142. When triggered by messaging system A 120, 
network service module A 140 allocates a conversation between messaging system A 120 and 
transaction management system A 1 50 by means of interface module A 142. A conversation is a 
logical connection that allows communications between applications on different nodes to 
proceed, while hiding the details of the underlying communication protocol from the 
communicating applications. In the disclosed embodiment, the allocated conversation carries 
message packets between messaging system A 120 and transaction management system A 150 
using network protocol 130. The communication link between RPG application A 1 10 and 

a 

transaction services A 170 is completed by a dialogue between transaction management system 
A 150 and transaction services A 1 70 based on network protocol 160. The message packets 
generated by messaging system A 120 include parameters, i.e. data and control information, 
necessary to activate one of transaction services A 170, carry on communications with the 
activated service, and terminate it. 
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Referring now to Fig. 8. there is a block diagram of a transaction service A 1 70, which 
comprises an instance of transaction management system A 150. including a client-server 
interface (CSI) A 154. a service application A3 10. a message conversion system A304, and a 
database management system (DBMS) A3 80. Service application A3 10 is a user provided 
module that includes functions for accessing data from DB A390 through DBMS A280. In the 
disclosed embodiment, DBMS A380 is Informix 7.0, and transaction management system A150 
is AT&T's TOP END. both of which conform to the X/Open distributed transaction processing 
(DTP) XA interface. Transaction management system A 150 also conforms to the DTP TX 
interface for communications with service application A3 10. 

Referring now to Fig. 7, there is shown a block diagram of messaging system A 120 
comprising a MSG module A210. a MSG Build/Parse module A220. a Listjiuild module A230, 
a memory management module A240, an inbound/outbound message buffer A218, and defined 
data structures A250 for coupling data between messaging system A 120 and RPG application 
Al 10. In order to make messaging system A120 portable between platforms, component 
modules A210. A220. A230, and A240 are written in C programming language. 

MSG module A210 includes a MSG API A2I2 through which RPG application A 1 10 
accesses functions A214 for initiating and terminating conversations with transaction 
management system A 150 and for requesting transaction processing services from server 
applications A3 10 accessed through transaction management system A150. In the disclosed 
embodiment. MSG module A210 also includes registered functions A216 ? which manipulate data 
between defined data structures A250 and MSG buffer A21 8 as described below. 

Build/Parse module A220 comprises a Build/Parse API A222. a data dictionary (DD) 
A228. message building/parsing functions A224. and a registered function (RF) API A226. 
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Build/Parse API A222 provides MSG module A210 with access to platform independent 
message building/parsing functions A224. DD A228 specifies the fields and field attributes of 
data segments that are recognized by an open system resource being accessed by RPG 
application Al 10. As discussed in greater detail below, DD A228 contributes to the flexibility of 
messaging system A 120, by providing a mechanism for altering its message building capabilities 
without requiring recoding of RPG application Al 10 or server applications A3 10. 

RF API A226 provides Parse/build module A220 with access to registered functions 
A216, which manipulate RPG data in defined data structures A250. Registered functions A216 
are specific to the data types of a platform, and including registered functions A216 in MSG 
module A210 removes any platform-dependence from Build/Parse module A220. For example, 
a substantially identical build/parse module A322 (Fig. 11) is employed by server application 
A3 10 on the open system platform. Build/Parse module A3 20 parses request message packets 
from RPG application Al 10 and builds response message packets to RPG application Al 10. 

List_buiid module A230 and MMS module A240 provides linked list building and 
memory allocation functions, respectively, for MSG module A210 and Build/Parse module 
A220. For example, when RPG application A 1 10 is initialized, it identifies to MSG module 
A210 all defined data structures it employs. MSG module A210 checks that the defined data 
structures have the proper number of parameters and calls List_build module A230 to generate a 
linked list of pointers to the defined data structures. List_build module calls on MMS module 
A240 as needed to allocate memory for the linked list. List_build module A230 and MMS 
module A240 are also used by MSG module A210 to eliminate the linked list when RPG 
application A 1 10 is terminated. 
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Typical service applications A3 10 provide RPG application A 110 with functions for 
searching and writing data to database A390 (Fig. 8). In order for RPG application A 1 10 to 
communicate with database A390, messaging system A 120 must employ in its data packets, data 
having attributes consistent with the columns of database A3 90. Since RPG application Al 10 is 
the ultimate source of data, messaging system A 120 must include some means of ensuring 
consistency between the attributes of the data segments employed by RPG application Al 10 and 
those of database A390. This is the function of defined data structures A250 and DDs A228, 
A328. 

Messaging system A120 provides utilities for generating DD A228 and DD A328 (Fig. 
1 1) and defined data structures A250 from a single source that includes attribute definitions 
consistent with those of database A390. This ensures that messaging system A 120 and service 
application A3 10 support the same vocabulary, which in turn ensures that RPG application Al 10 
and database A390 can communicate. The single source from which DDs A238, A328 and 
defined data structures A250 are generated is ASCII definition file (ADF) A260. 

Referring now to Fig. 9, there is shown a block diagram indicating the relationship 
among ADF A260. DDs A228. A328. and defined data structures A250. ADF A260 is a human- 
readable file that includes descriptions of the attributes of every field of every data segment in 
the system. As noted above, the attributes of a segment correspond to the columns (attributes) of 
the database A390. ADF A260 also includes a header segments, which are used to indicate 
which service application A3 10 is being requested by RPG application Al 10. Header segments 
include control information for error codes and messages, and those header segments associated 
with sen-ice applications A3 10 that require data input from RPG application Al 10. have 
appended the data segments corresponding to the required data. ADF A260 also includes a list 
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of restricted segments, which are segments that may only be used by selected service 
applications A3 10. ADF A260 is typically generated through a GUI design tool, which in the 
preferred embodiment of the invention, is Visual Builder Tool (VBT). In essence, ADF A260 
specifies the vocabulary understood by database A390. 

Also shown in Fig. 9 is a Data_Structure Utility (DSU) A270 which is used to generate 
defined data structures A250 from ADF A260 whenever ADF A260 has been modified. In 
particular, DSU A270 reads ADF A260 and uses Lisr Build module A230 to generate a linked 
list of fields and a linked list of segments from the entries in ADF A260. For every segment in 
the segment linked list DSU A270 retrieves attributes of the component fields from the field 
linked list and writes the information to a DDS A250. Defined data structures A250 arc then 
written to a file, which is linked to RPG application Al 10 and messaging system A 120 as an 
externally defineci data structure. 

There are two defined data structures for each data segment defined in ADF A260. 
Application request data structures (ARDS) A252 are loaded with data by RPG application A 1 10 
to provide messaging system A 120 with the data it needs to a build a message to a service 
application A3 10. Application response data structures ( ASDS) A254 are written by messaging 
system A 120 to communicate a response from service application A3 10 to RPG application 
A110, following parsing by Build/Parse module A220. A single application control data 
structure (ACDS) A256 is used by RPG application A 1 1 0 to communicate service application 
requests to messaging system A 120. 

Also shown in Fig. 9 is a utility, DDBIN A280. that reads ADF A260 and generates DD 
A228 as a binary file sorted by segment names. DDBIN A280 also creates a summary 
information field for DD A228, including the total number of segments, offsets into DD A228 
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for alphabetically sorted segments groups, and an offset into the file for a restricted segment file 
(RSF). DD A228 may be linked into Build/Parse module A220 as an include file. Alternatively, 
the contents of DD A228 may be read into a segment cache A325 (Fig. 11) associated with 
Build/Parse module A220. as needed, to facilitate access to segment information. This latter 
alternative is employed in messaging conversion module A304 (Fig. 8) which is used for 
message packet building/parsing by service application A3 10. 

Referring now to Fig. 10, there is shown a representation of an ACDS A256 that is used 
by RPG Al 10 to request services of messaging system A120. ACDS A256 is also used by 
messaging system A 120 to provide information on the status of requested services to RPG 
application Al 10. A single ACDS A256 is used by RPG application Al 10 to indicate which of 
transaction services A 160 is being requested. Details of the requested service are provided in the 
following fields of ACDS A256: (1) Request Service Name. (2) Sending Segments, and (3) 
Hold Context Flag. 

Request Service Name is a field in which the name of a service application A3 10 
available through transaction management system A 1 50 is specified. A corresponding header 
segment defined in ADF A260 is used by messaging system A 120 to indicate to transaction 
management system Al 50 the type of service being requested. As noted above, some service 
applications A3 10 require that RPG application Al 10 provide data along with the service 
request. In these cases, the Sending Segments field is used by RPG application to specify which 
ARDs A252. if any. contain the required data. Each such ARDS A252 is specified in the 
Sending Segments field by the Segment Name of the data it contains. In the preferred 
embodiment of the invention, the name of each data segment to be sent is concatenated and 
delimited by a pipe (T). Fox example, where data from three ARDs A252 corresponding to a 
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name (NAME), business address (BUS), and home address (HOME) will be sent to sendee 
application A3 10 specified by ACDS A256. the Sending Segments field will be 
NAME|BUS|HOME Data provided in response to a service request is sent from service 
application A3 10 to messaging system A 120 as data segments. Messaging system A 120 makes 
any necessary data conversions and forwards the convened data segments to RPG application 
A110 using the corresponding ASDSs A254. 

Hold Context Flag is set when RPG application Al 1 0 will retain an on-going 
conversation with a service application A310 as. for example, when RPG application Al 10 will 
submit sequential service calls to service application A3 10. 

The Results Services fields of ACDS A256 comprises Return Status Code. Initialized 
Flag, and Control Flag fields. Messaging system A 120 uses these to indicate to RPG application 
A 1 10 the status of a service request. Return Status Code is zero, unless an error has occurred in 
the Service Request. Initialized Flag is set when messaging system A120 is properly initialized 
and is zero otherwise. Control Flag indicates the status of messaging system A120. It is zero by 
default, four when a service application A3 10 is currently holding context, and some non-zero 
value other than four when a failure occurs in messaging system A 120. 

The interactions between RPG application Al 10 and messaging system A120 will now 
be described from initialization through termination of RPG application Al 10. As noted above, 
messaging system A120 is initialized through a function call from RPG application Al 10 during 
its initialization. The initializing function call includes a parameter list specifying the segment 
name, segment address, and number of occurrences of each ARDS A252 and ASDS A254 used 
by RPG application A 1 10 to send data to and receive data from MSG module A210. The 
parameter list also specifies the name and address of ACDS A256 used by RPG application 
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A110 to communicate control information to MSG module A210. Addresses tor ARDS A252. 
ASDS A254. and ACDS A256 (collectively. DDSs A250) are in shared memory location Al 14. 

On initialization. MSG module A210 first checks that DDs A250 are specified properly 
(3 parameters for each ARDS A252 and ASDS A254 and 2 parameters for ACDS A256). MSG 

5 module A210 then calls initializing functions in Build/Parse module A220. List_build module 
A230. and MMS module A240. initializes a conversation with transaction management system 
A 150 via network services A 140 and IF A 142. and waits for a verification message that the 
conversation has been established. At this time, transaction management system A 150 
establishes a dialogue with transaction services A 160 on open system server A 192. MSG 

in module A210 then calls ListJ>uild module A230 to generate a linked list of pointers to DDSs 
A250, and List_BuiId module A230 calls MMS module A240 as needed to allocate memory for 
the linked ;ist 

Once conversation/dialogue links have been established between messaging system A 120 
and transaction management system A 150, RPG application Al 10 accesses a requested service 

is application A3 1 0 of transaction services A 1 60 through transaction management system A 1 50, 
using messaging system A 120 as an application program interface (API). RPG application Al 10 
initiates a request for services by loading the Request Service Name and Sending Segments List 
fields of ACDS A256 with the segment name of the service being requested and the segment 
names of any data being sent to the requested service. RPG application Al 10 also loads each 

20 ARDS A252 named on the Sending Segments List with the data to be sent. 

When ARDSs A252 and ACDS A256 are loaded. RPG application A 110 calls the request 
function in MSG module A210, including the names of ACDS A256 and ARDS A252 in a 
parameter list associated with the function call. MSG module A210 use the request function to 
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clear the Results Services fields of ACDS A256 and read the Request Service Names and 
Sending Segments List fields of ACDS A256. MSG module A2 10 writes a control/status header 
(see below) to message buffer A 1 18. specifying Request Service Name, a user identification 
(userid), and status data for transaction management system A 150. MSG module A210 also 
$ calls the Build MSG function in Build/Parse module A220 with the parameter list specifying the 
names of the data segments and the location of the message buffer A218. 

Build/Parse module A220 handles the conversion and manipulation of data between the 
DDSs A250 identified in the parameter list and message buffer A218. As noted above, the 
Build/Parse MSG functions of module A220 use registered functions A216 to accomplish the 
io actual data manipulation between DDSs A250 and message buffer A218. For outbound 
messages, the Build MSG function uses DD A228 to determine the required form for each 
segment to be included in the message packet and makes the necessary format conversions. DD 
A228 is also used on inbound message packets to convert data to a format appropriate to the 
operating system of the AS/400. The addresses of DDSs A250 are determined from the link list 
is generated on initialization. 

The message packet generated by messaging system A 120 has the following form: 

(I) | error | control | function code | userid [ data |. 

< - control/status ► | « application data ► 

The header, comprising error, control, function code, and userid fields, provides the routing and 
20 status information necessary to transfer the service request and associated data of RPG 
application A 1 1 0 from messaging system A 120 to requested service application A3 1 0. In 
particular, the error field includes error codes for tracking purposes, the control field specifies the 
status of communications with transaction management system A150, the function code field 
specifies which service application A3 10 is being requested, and for security checking purposes, 
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userid identifies the person(s) using RPG application Al 10. The data field comprises the service 
name and any application data, suitably formatted, thai is being transferred between RPG 
application A 1 10 and service application A3 10. As discussed above, this data is loaded by 
messaging system A 120 using Parse/Build module A220. 

5 Once the message packet has been completed. MSG module A21 0 calls a send/receive 

function to forward message packet to transaction management system A 1 50 in gateway server 
A152, using the conversation allocated on initialization. Interface module A 142 maps the 
conversation to the dialogue established between transaction management system A 150 and 
transaction services A 160. determines from the function code in the header of message packet (I) 

m which service application A3 10 is targeted, and uses transaction management system A 150 to 
call targeted service application A3 10. 

Referring now to Fig. 1 L there is shown a detailed block diagram of message conversion 
module A304 comprising a message build/parse module A320, a list_build module A330, and a 
memory management system (MMS) module A340, which perform functions for the open 

is system platform of server A 192 that build/parse module A220, list_build module A230. and 
MMS module A240 perform on the proprietary platform of AS/400 A 1 1 2. In the case of server 
A192. however, transaction management system A150 operates in conjunction with CSI A154 to 
handle routing and control information. In particular, these components ensure that the data 
portion of message packet (I) is routed to service application A3 10. Consequently, these is no 

20 need for a counterpart of MSG module A2 1 0 on server A 1 92. On the other hand, the data 
portion of message packet (I) must be converted into a format suitable for the open system 
platform, and this is the function performed by modules A320, A330. A340. 
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As indicated in Fig. 11. service application A3 10 has associated registered functions 
A3 16 that isolate platform-independent, build/parse module A320 from platform specific 
message (MSG) buffers A3 14. A3 1 8. In this case, MSG buffer A218 includes data structures for 
coupling data between message conversion module A304 and DBMS A3 80 in a format 
consistent with that of database A3 90. MSG buffer A218 provides a buffering function for 
message packets inbound from transaction management system A 150 and outbound to 
transaction management system A 150. List_build module A330 and MMS A340 also provide 
essentially the same functions as their counterpart modules A230, A240 on AS/400 Al 12. 

Message conversion module A304 also differs from messaging system A 120 in that it 
uses a segment cache A354 and segment cache interface structure (SCIS) A352 to facilitate 
access to the information data dictionary (DD) A326 without including the entire file in 
Build/parse module A220. SCIS A352 includes information for tracking accessed data segments 
in segment cache A354. This is an alternative configuration to that employed on AS/400 Al 12, 
but it requires sufficient memory for segment cache A354. 

While the configuration of computer system A100 shown in Fig. 6 provides the necessary 
communication between an RPG application A 1 10 and transaction services A 170. it does not 
provide security or accounting functions where transaction management system A 150 is TOP 
END (TE) and IF A 142 is an inbound agent (IA) spawned by network services module A 140 
when messaging system A 1 20 is initialized. In particular, IA A 142 is configured to map all 
conversations/dialogues having the same transaction program name (TE sign-on name) and 
transaction code (Request Service Name) to a generic userid. Consequently, all users of a given 
service application 310 will be assigned the same userid, independent of which user(s) of RPG 
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application Al 10 actually initiated the transaction. If not addressed, this circumstance 
effectively eliminates security checking and accountability for transactions to server A 192. 

In order to ensure both security checking and accountability for transactions to server 
A192. the preferred embodiment of system A100 incorporates a security service (SIGNON 
SECURITY SERVICE, SSS) A 154 in the TE transaction management system A 150 on gateway 
server A152. Referring now to Fig. 12, there is shown a block diagram of a preferred 
configuration for gateway, server A 152, in which transaction management system A 150 is 
coupled to transaction services A160 through SSS A154. SSS A154 comprises a TE client A156 
and a TE server A 156' coupled back-to-back through a client/server interface (CSI) provided by 
transaction management system A 150. 

I A A 142 incorporates an integral client which accesses SSS A 154 through transaction 
management system A 1 50 on behalf of messaging system A 120. On initialization of messaging 
system A120. network services module A140 spawns IA A142, which forwards a SIGNON 
message, including a non-generic userid to transaction management system A150. IA A142 
establishes a dialogue with SSS A 154 by passing a request for SSS services through transaction 
management system A150. using the generic userid provided in the configuration file of IA 
A142. Transaction management system A150 forwards the request to SSS A154, establishing a 
dialogue between TE server A 1 56 and RPG application Al 10 (via messaging system A 120). TE 
server A 156 then triggers TE client A 156* to sign onto transaction management system A150 
using the non-generic userid embedded in the signon message. SSS A154 confirms to messaging 
system A 120 that the dialogue has been established, and sets a flag holding the dialogue open. 
Thereafter, transaction services A 170 are accessed by TE client A 156' in response to message 
packets (I) from messaging system A 120. 
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WHAT WE CLAIM IS: 



1. A computer implemented method for differentiating a customer at a casino 
property from other customers, the method comprising: 

establishing a status of the customer from at least one of an accumulated points 
of the customer or a theoretical win profile of the customer; 

providing at the casino property a gaming machine having a physical 
instrumentality adjacent thereto, the instrumentality being selectively activateable; 

detecting an identity carrier of the customer at the gaming machine having the 
physical instrumentality; 

determining the status of the customer; and 

responsive to the status of the customer being a special status, activating the 
physical instrumentality for the benefit of the customer. 

2. The method of claim 1 , wherein establishing a status of the customer from at 
least one of an accumulated points of the customer or a theoretical win profile of the customer 
further comprises: 

monitoring betting activity of the customer at any of a plurality of casino 

properties; 

determining at least one of: 

a theoretical win profile for the customer as a function of estimated 
winnings from the monitored betting activity of the customer at the plurality of casino 
properties over a time period, the theoretical win profile for subsequently determining 
complementaries or services to be provided to the customer; or 

an accumulated point balance for the customer according to a monetary 
value of the monitored betting activity of the customer at any of the plurality of casino 
properties. 
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3. The method of claim 1, further comprising: 

responsive to the status of the customer being a special status, providing a 
distinguished service to the customer, the distinguished service limited to customers having the 
special status. 

4. The method of claim 1 , further comprising: 

periodically updating the theoretical win profile for the customer as a function 
of estimated winnings from betting activity of the customer monitored at any of a plurality of 
casino properties over a time period, the theoretical win profile for subsequently determining 
complementaries or services to be provided to the customer. 

5. The method as in any one of the foregoing claims, wherein detecting the 
customer at the gaming machine comprises: 

detecting a customer identity carrier storing data identifying the customer. 

6. The method as in any one of claims 1 -5, wherein the physical instrumentality 
is a light, and wherein activating the physical instrumentality for the benefit of the customer 
comprises activating the light. 

7. The method as in any one of claims 1-5, wherein the physical instrumentality 
is a telephone and wherein activating the physical instrumentality for the benefit of the 
customer comprises activating the telephone. 

8. The method as in any one of claims 1-5, wherein the physical instrumentality 
is a cabinet having an interior compartment with a selectively activateable lock, and wherein 
activating the physical instrumentality for the benefit of the customer comprises enabling the 
lock of the compartment of the cabinet. 
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9. The method as in any one of claims 1-5, further comprising: 

providing a privileged facility with a door having a selectively activateable lock 

to allow customers having the special status into the privileged facility; and 

unlocking the door of a privileged facility to allow a customer having the special 

status to enter the privileged facility. 



1 0. The method as in any one of claims 1 -5, further comprising: 

providing a privileged facility with a door having a selectively activateable lock 
to allow customers having the special status into the privileged facility; 

detecting the customer at the door of the privileged facility; 
determining the status of the customer; and 

responsive to the status of the customer being a special status , unlocking the 
door of a privileged facility to allow the customer having the special status to enter the 
privileged facility. 

11. The method of claim 3 wherein providing a distinguished service comprises: 
providing the customer with an express food or beverage service. 

12. The method of claim 3, wherein providing a distinguished service comprises: 
providing the customer with preferred seating at an entertainment establishment. 

13. The method of claim 3, wherein providing a distinguished service comprises: 
providing the customer with preferred seating at a dining establishment. 

1 4. The method of claim 4 wherein periodically updating the theoretical win profile 
of the customer comprises: 

updating the theoretical win profile for each separate visit of the customer to any 
of one of the plurality of casino properties. 
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15. The method as in any of the foregoing claims, further comprising: 

at each of a plurality of casino properties, providing a computer-implemented 
management system, at least one input device coupled to the management system for 
transferring activity data of a customer to the management system, and a physical 
instrumentality proximate the input device, 

providing a central database server and coupling the management system of 
each casino property to the central database server; 

at each of the plurality of casino properties, assigning a customer ID and a 
corresponding customer account to each of a plurality of customers at the casino property, and 
storing the customer ED and corresponding customer account assigned at the casino property 
in the management system at the casino property, each customer account at a casino property 
including at least one of the accumulated point balance from betting activity of the customer 
at that casino property or the theoretical win profile of the customer; 

forming, from the customer accounts in each of the management systems at the 
plurality of casino properties, a database of customer accounts in the central database server, 
each customer account in the database accessible through the corresponding customer ED, each 
customer account in the central database including a status field indicating the status of the 
customer as a function of either the accumulated point balance or the theoretical win profile 
of the customer; 

and wherein determining the status of the customer and activating the physical 
instrumentality comprises: 

monitoring at least one input device at a casino property for activity data 
of a customer, including a customer ID, to detect a presence of the customer; 

responsive to detecting a customer ID, determining whether the 
corresponding customer account is activated in the management system of the casino property; 

responsive to determining that the corresponding customer account is 
activated in the management system, updating the corresponding customer account with the 
activity data of the customer monitored at the input device; and 
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responsive to determining that the corresponding customer acctfuht is 
not activated in the management system, copying selected activity data of the customer from 
the corresponding customer account in the central database server to the management system 
at the casino property to activate the customer account in the management system at the casino 
property, the selected activity data including the status field of the customer account. 

1 6 The method of any one of claims 1-14, further comprising: 

providing at the casino property, a computer-implemented management system, 
at least one input device coupled to the management system for transferring activity data of a 
customer to the management system, and a physical instrumentality proximate the input device, 
coupling the management system to a central database server; 
assigning a customer ID and a corresponding customer account to each of a 
plurality of customers at the casino property, and storing the customer ID and corresponding 
customer account assigned at a casino property in the management system at the casino 
property, each customer account at each casino property including the theoretical win profile 
for the customer; 

establishing the status of the customer in the customer account as a function of 
the theoretical win profile of the customer, and wherein detecting the customer comprises: 

monitoring at least one input device at the casino property for activity data of 
a customer, including a customer ID to detect a presence of the customer; 

responsive to detecting a customer ID, determining the status of the customer 
in the customer account. 

17. A gaming system for a casino property, the gaming system comprising: 
a gaming machine; 

a physical instrumentality adjacent to the gaming machine; 
identification means, coupled to the gaming machine, for obtaining from an 
identity carrier an identification signal identifying a customer at the gaming machine; 
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determination means, coupled to the identification means to receive the 
identification signal, and for determining a status of the customer by providing the 
identification signal to a computer system storing for each customer a status of the customer 
based on at least one of an accumulated points of the customer or a theoretical win profile of 
the customer, and receiving a signal of the status of the customer from the computer system; 
and 

activation means, coupled to the determination means and the physical 
instrumentality, and responsive to the status signal indicating a special status of the identified 
customer, for activating the physical instrumentality for the customer's benefit or use. 

18. The system of claim 17, wherein the physical instrumentality is a telephone 
adjacent to the gaming machine, the telephone coupled to the activation means to be activated 
in response to the status signal indicating a special status customer. 

19. The system of claim 17, wherein the physical instrumentality is a cabinet 
adjacent to the gaming machine, the cabinet having an interior compartment with an electrically 
activateable lock coupled to the activation means to be activated in response to the status signal 
indicating a special status customer to allow the customer to selectively lock and unlock the 
compartment. 

20. The system of claim 17, further comprising a privileged facility with a door 
Having a lock that is selectively activateable in response to an activation signal from the 
activation means to allow a customer having a special status to enter the privileged facility. 

21 . The system of claim 17, wherein the physical instrumentality comprises a light 
coupled to a gaming machine. 



-53- 



22 . The system of any one of claims 17-21, for differentiating a customer from other 
customers at any of a plurality of casino properties, wherein the computer system comprises: 
a management system for receiving the identification signal, the identification 
signal comprising a customer ID, and to further receive customer betting data, the management 
system being further coupled to a central database for selectively providing the received 
customer betting data and customer ID to the central database, and for providing a status signal 
indicating the status of the customer to the determination means; 
the central database comprising: 

a plurality of customer accounts for the customers, each customer 
account of a customer including: 

a customer ID; 
at least one of: 

a theoretical win profile for the customer as a function of 
estimated winnings from the betting activity of the customer at the plurality of casino 
properties over a time period, the theoretical win profile for subsequently determining 
complementaries or services to be provided to the customer; or 

an accumulated point balance from betting activity at the 

plurality of casino properties; 

a status field indicating the status of the customer as a function 
of at least one of the theoretical win profile or the accumulated point balance, the status 
selected from a group including at least a special status and a non-special status; and 

a database management program for receiving customer betting 
activity data and a customer ID for a customer from a management system, updating either the 
theoretical win profile or the accumulated point balance as a function of the received betting 
activity data, and updating the status field of the customer in the customer account in the 
central database corresponding to the received customer ID as a function of the updated 
theoretical win profile on the accumulated point balance. 
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23 . The system of any one of claims 17-21, for differentiating a customer from other 
customers at the casino property, the computer system comprising: 

a management system for receiving the identification signal, the identification 
signal comprising a customer ID, and to further receive customer betting data, the management 
system being further coupled to a central database for selectively providing the received 
customer betting data and customer ID to the central database, and for providing a status signal 
indicating the status of the customer to the determination means; 
the local database comprising: 

a plurality of customer accounts for the customers, each customer 
account of a customer including: 

a customer ID; 

a theoretical win profile for the customer as a function of estimated 
winnings from the betting activity of the customer at the casino property over a time period, 
the theoretical win profile for subsequently determining complementaries or services to be 
provided to the customer; and 

status field indicating the status of the customer, the status selected from 
a group including at least a special status and a non-special status; and 

a database management program for receiving customer betting activity 
data and a customer ID for a customer from a management system, and updating the status field 
of the customer in the customer account in the local database corresponding to the received 
customer ID as a function of the theoretical win profile. 

24. The system of any one of claims 17-21, for differentiating a customer from other 
customers at the casino property, the computer system comprising: 

a database of customer accounts for a plurality of customers, each customer 
account having customer identification data identifying the customer and a status field 
indicating the status of the customer, the status selected from a group including at least a 
special status and a non-special status, the status field for each customer determined by the 
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computer system based upon at least one of an accumulated points of the customer or a 
theoretical win profile of the customer, the computer system further responsive to the gaming 
machine having the physical instrumentality to receive the signal identifying the customer, and 
to determine from the database the status of the identified customer, the gaming machine 
responsive to the status of the customer being a special status by activating the physical 
instrumentality for the benefit of the customer. 

25. The system of any one of claims 17-21, wherein the identification means 
comprises: 

a card reader coupled to the computer system to read customer identity 
information from a customer identity card and provide the customer identity information to the 
computer system. 

26. The system of any one of claims 17-21, wherein: 

the determination means comprises a logic unit coupled to receive a status 
signal from the computer system indicating the status of the customer, and to selectively 
provide an activation signal in response to the status of the customer being a special status to 
the activation means; and 

the activation means further comprising a relay unit coupled to the logic unit 
and having a plurality of relays for selectively activating the physical instrumentality coupled 
to one of the relays in response to the activation signal from the logic unit. 

27. A computer-implemented method for differentiating a customer from other 
customers at a casino property, comprising: 

operating a computer system including a database of customer accounts for a 
plurality of customers, each customer account of a customer having: 
customer identity data of the customer; 
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a theoretical win profile for the customer as a function of estimated winnings 
from the betting activity of the customer at the casino property over a time period, the 
theoretical win profile for subsequently determining complementaries or services to be 
provided to the customer; and 

a status field indicating the status of the customer, the status selected from a 
group including at least a special status and a non-special status, 

periodically updating the status in the customer account of a customer as a 
function of a current theoretical win profile of the customer; 

providing a gaming machine comprising a card reader and a light; 

reading at the card reader of the gaming machine a customer identity card of a 
customer to obtain customer identity data encoded thereon; 

determining a status of the customer account corresponding to the read customer 

identity data; 

responsive to the status of the customer being a special status, activating the 
light at the gaming machine; and 

providing a distinguished service to the customer at the gaming machine, the 
distinguished service limited to customers having the special status. 
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